Currently, one of the most pressing problems in the antivirus industry is the issue of keeping antivirus databases up to date. In fact, even in the short time in which a malware program has not yet been detected by the leading antivirus experts and companies, it can be downloaded hundreds of thousands of times by different users and can infect a great number of computers. Timely updating of antivirus databases permits the combat against malware to be adequately and rapidly carried out.
But it is worth noting that the quantity of software, including malware, is constantly increasing, in which connection proactive methods of detecting similar applications are necessary. To combat unknown malware, modern antivirus companies are employing the methods of heuristic analysis, the execution of unknown programs in a protected environment (e.g., sandbox, honeypot) with the use of virtualization, and various means of limiting the functionality of programs based on an analysis of their activity (e.g., HIPS). Nevertheless, one cannot totally rely on all of the procedures enumerated above, since they possess definite deficiencies associated with both the specifics of their operation and their use in current antivirus applications in which the user has the right to establish settings that do not offer the full use of these technologies since they can take up a considerable amount of time and resources, for example when launching unknown programs. Before verification of unknown programs is completed, a user can, for example, disable their execution in a protective environment in the form of a sandbox, or else reduce the time that is allocated to emulation.
In connection with the possible risks of inefficient operation of proactive technologies, and in view of the constant increase in the number of malware programs, so-called “whitelists” have become more and more popular: databases of clean, i.e., verified and reliable, objects. A list of clean objects is constructed for files, applications, links, and e-mail messages, as well as for user-account records on instant-messaging systems, message-exchange logs, IP addresses, host names, domain names, and so forth. It is possible to compile similar lists starting from many factors: the presence of an electronic signature or other manufacturer data, data about the source (where the application was obtained), data about application links (parent-child relationships), data on the application version (e.g., an application can be considered verified, proceeding from the fact that the previous version was also in the list of verified programs), data on environmental variables (e.g., operating system, startup parameters), etc. Before each release of updates to signatures for antivirus databases, they must be checked against collisions for example, with the “whitelist” of files. It is worth noting that the majority of unknown executable files under study at a given time are so-called PE (Portable Executable) files and they have the PE format (for the Windows family of operating systems, under which most malware is written). A PE file can be represented in the form of a header, a certain number of sections that comprise the form of an executable program, and an overlay, which is a program segment loadable as needed during execution. At the present time, various unique parts of the file are being used in an attempt to create a file signature. Most often, code from a section of code is used for these purposes. However, situations are not unusual in which an expert will erroneously interpret a library or other widely used code as part of malware because this fragment is present in malware. In this case, a signature may be created that is erroneously applied to this widely used fragment. This signature will successfully detect a malware application, but this signature will also define as malicious all other files that contain this code fragment but are clean. As a result of this error, a false detection takes place.
The operation of antivirus applications is, one way or another, associated with some antivirus records for example, rules, templates, lists, and signatures, in the creation of which an expert generally participates, as a rule. These antivirus records permit malware to be detected and removed. But the human factor is also not excluded in this process, and an expert can make a mistake, for example, after creating a signature that will determine to be malicious some clean software, information about which is in a “whitelist” of files. It must also be noted that it is not just the expert who can make a mistake. Systems exist for the automatic development of antivirus records, which, in attempting to detect as much malware as possible, will inevitably also encompass some clean applications.
Accordingly, a need arises for a method for correcting antivirus records contained in antivirus databases in order to minimize false malware detections.